1. Field of Invention
Enterprise Architecture (EA) is the field that is concerned with analyzing how business processes work within an organization and how technology can be leveraged to improve those processes. The term EA can refer either to the discipline that defines how such an analysis is done or to a specific analysis of a specific organization.
2. Prior Art
There are many ways an EA can be valuable to an organization. For example, an EA can help find redundancies and thereby identify opportunities to consolidate functionality. An EA can be used to find inefficient processes and identify opportunities to use technology to improve those processes. An EA can be used to find non-critical business processes that can be outsourced, allowing the organization to focus on the critical differentiating processes that define competitive advantage.
EA efforts are typically very expensive. The cost is dominated by three primary factors:                The exhaustive timeframes over which analysis takes place        The large number of highly placed internal staff that become absorbed by the process        The army of expensive consultants that are necessary to navigate through the complex methodologies        
Despite the considerable investment in EA, far too often the efforts result in failure. A good example of such failures can be seen in the United States Federal Government, an organization that has invested billions of dollars in EA. Yet despite these efforts, hardly a month goes by in which the Government Accountability Office (GAO), an independent watchdog branch of the U.S. Government, does not issue a scathing report on the failures of some government agency to effectively make use of EA. It seems that the more critical the government agency, the more likely it is to have major EA failures.
A recent article in IEEE Spectrum included this gloomy assessment:                “Looking at the total investment in new software projects—both government and corporate—over the last five years, I estimate that project failures have likely cost the U.S. economy at least $25 billion and maybe as much as $75 billion. Of course, that $75 billion doesn't reflect projects that exceed their budgets—which most projects do. Nor does it reflect projects delivered late—which the majority are. It also fails to account for the opportunity costs of having to start over once a project is abandoned or the costs of bug-ridden systems that have to be repeatedly reworked.” (Why Software Fails, by Robert N. Charette in IEEE Spectrum, September, 2005, available at http://www.spectrum.ieee.org/sep05/1685)        
Anytime we see a major failure of a software effort, the cause can be directly traced to a failure to apply EA methodologies.
One of the most common reasons for EA failure is complexity. As business processes and technology both increase in complexity they become increasingly difficult to understand, and if they are not understood, alignment between the two becomes all but impossible.
As Richard Murch succinctly put it in a recent article in InformIT,                 “To let IT infrastructures and architectures become increasingly complex with no action is unacceptable and irresponsible. If we simply throw more skilled programmers and others at this problem, chaos will be the order of the day . . . . Until IT vendors and users alike solve the problem of complexity, the same problems will be repeated and will continue to plague the industry.” (Managing Complexity in IT, Part 1: The Problem in InformIT, Oct. 1, 2004 By Richard Murch)        
There are a number of EA methodologies today, the three most common being The Open Group Architectural Framework (better known as TOGAF), The Zachman Framework for Enterprise Architecture (better known simply as Zachman), and the Federal Enterprise Architecture (better known as FEA).
All of these methodologies share some commonality. All start by exhaustively analyzing the business processes. They then continue with an exhaustive analysis of the current technical architecture and finally they exhaustively analyze the desired architecture.
Theses processes are slow and cumbersome, often taking a year or more to complete and sometimes require the full-time efforts of a dozen people or more. Frequently, by the time the process is completed, the fundamental business problems that drove the effort in the first place have changed and the solutions are no longer relevant. Many times the process is abandoned before the effort has been completed.
Even when EAs are produced, existing methodologies offer no means to evaluate the results. There is no way to tell of the resulting enterprise architecture is good, bad, or indifferent. Only by going through the hugely expensive step of implementing the designs will one find out if the designs themselves were any good.
Existing EA methodologies are highly subjective, with architectural decisions guided only by the personal experience, opinions, and preferences of the practitioner. This means that different practitioners are likely to come up with substantially different results